[WIP] diagnostics_channel: add meta buil-in channels#61943
[WIP] diagnostics_channel: add meta buil-in channels#61943simon-id wants to merge 2 commits intonodejs:mainfrom
Conversation
Signed-off-by: simon-id <simon.id@protonmail.com>
|
@BridgeAR I am absolutely finishing this, but I'm still struggling to compile this for some reason. Started with fresh repo and all but can't get any usable compilation error message, so I'm working blind currently. I'll try to get it to compile on a colleague's machine next week 👍 |
Qard
left a comment
There was a problem hiding this comment.
Seems reasonable. It would be good to see a benchmark of the impact on a publish without subscribers though.
Publish on an inactive channel was intentionally a no-op to have the least possible performance impact when a channel does not have subscribers. With this it has at least an extra hasSubscribers check, and possibly a very noisy publish.
My worry with capturing all publishes everywhere automatically is that if a lot of channels exist, which is encouraged by diagnostics_channel, the performance impact could be substantial. I think I would prefer to have a special channel to publish to whenever a new channel is created. That way you could just listen to that and decide for each channel if you want to attach a subscriber to capture all events from it.
What
This add DC (
diagnostics_channel) built-in events, for DC itself. Just likehttp,console, orprocess, have built-in events that can be subscribed to, to monitor code, this make it possible for DC to be monitored through DC.Why
It appeared that multiple people working with DC channels extensively ended up monkey-patching DC in their test app or test suite, to allow some actions to be logged. Now instead of monkey-patching, they can just listen to these events.
It also allows one to create a kind of "dead-letter queue" DC subscription, that will catch all events that were not delivered: